home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7650 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB

  1. Path: galaxy.ucr.edu!not-for-mail
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Newbie Q: references
  5. Date: 24 Feb 1996 19:59:38 GMT
  6. Organization: University of California, Riverside Department of Computer Science
  7. Message-ID: <4gnqna$5hv@galaxy.ucr.edu>
  8. References: <4fegaq$gvc@dns.plano.net> <4figeu$24l@news1.usa.pipeline.com>
  9. NNTP-Posting-Host: corvette.ucr.edu
  10. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  11.  
  12. grantp@usa.pipeline.com wrote:
  13. [...]
  14. : No.  Most implementations pass the reference the same way as a 
  15. : pointer.  In other words, the only difference between a pointer 
  16. : and a reference to an object is the semantics in the language. 
  17.  
  18. Once they are intialized references behave exactly like pointers,
  19. except that they are automatically dereferenced -- think of a pointer
  20. with an invisible "*" in front of it.  (As a consequence, you can't
  21. modify (reinitialize) references, because all attempts to do so will
  22. be referred to the referent.)
  23.  
  24. Regarding initialization, there is the difference that references can
  25. be initialized to refer to an expression, in which case a temporary is
  26. created to hold that expression.  Also, when initialized by the
  27. catching of an exception, references and pointers behaved in vastly
  28. different ways -- see "More Effective C++" by Scott Meyers for
  29. details.
  30.  
  31. As types, there are significant limitations on how references can be
  32. used in building further types, e.g., arrays of references are out, as
  33. are pointers to references.  There are a couple of other quirks as
  34. well.  Reference members destroy the "PODness" of a struct, freeing it
  35. from the constraint of C-compatible layout.  Also, we have the
  36. absurdity that sizeof(Widget&) is sizeof(Widget) regardless of the
  37. number of bytes used to encode references.  (The April draft standard
  38. doesn't say this but members standards committee assure me its what
  39. they intend, and it is how they've written their compilers.)
  40.  
  41. One can have delightful metaphysical arguments about whether or not
  42. references are objects, or simply "aliases."  We know from first
  43. principles that they occupy run-time data storage, which is the
  44. definition of what it means to be an "object."  But, if you try to
  45. find the address of that storage, references being what they are,
  46. you'll only get the address of the referrent.  Some argue that, if you
  47. can't find its address, it doesn't have one, and. if it doesn't have
  48. one, it's not an object.  (If a tree falls in the forest and no one
  49. hears it ... )
  50.  
  51. References are not always aliases, since they can refer to nameless
  52. objects, as does the intger reference returned by 
  53.                int& f(){ return * new int; }
  54. and aliases are names, which are uses of identifiers.
  55.  
  56.  
  57. Tom Payne (thp@cs.ucr.edu)
  58.